<html>
<head><meta charset="utf-8"><title>stdarch-gen and neon · t-compiler/arm · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/index.html">t-compiler/arm</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html">stdarch-gen and neon</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="232263786"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232263786" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jamie Cunliffe <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232263786">(Mar 29 2021 at 13:02)</a>:</h4>
<p>I have recently been looking at alternatives to stdarch-gen for generating the neon intrinsics (and potentially other future intrinsics) with less manual work (i.e. the writing of neon.spec). This has included looking at changing llvm tablegen to emit rust and using clang and extracting llvm functions from the ir.<br>
Given the recent pull requests by <span class="user-mention" data-user-id="353056">@Sparrow Li</span>  and <span class="user-mention" data-user-id="353941">@surechen</span>  it's looking like it could be less work to finish the neon intrinsics with the existing stdarch-gen.<br>
I'm reaching out to see if there is a desire to continue on with something that's a little more automated for neon, when we come to look at SVE it might be worth looking at something with a little less manual work, or to offer time to work on the remaining ones with the existing generator.</p>



<a name="232338758"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232338758" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232338758">(Mar 29 2021 at 21:24)</a>:</h4>
<p>I think moving towards more automation is a good thing.</p>
<ul>
<li>I also looked at using TableGen in the past but found it impractical since a lot of the generated intrinsics simply call a <code>__builtin_</code> which is then lowered to LLVM IR using custom code in Clang.</li>
<li>Something easier to do is to automatically generate tests with random inputs and then compare the results to that of the equivalent C code.</li>
</ul>



<a name="232339153"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232339153" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232339153">(Mar 29 2021 at 21:27)</a>:</h4>
<p>SVE intrinsics are complicated to support because the  SVE types don't behave like normal types: they have an unknown size at compile time but can still be passed around by value unlike Rust DSTs. This also applies to the RISC-V vector extension.</p>



<a name="232403626"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232403626" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Bramley <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232403626">(Mar 30 2021 at 10:27)</a>:</h4>
<p>We've been talking about SVE types a little, and what we might need to do to support them. My instinct is some <code>CpuSized</code> trait alongside <code>Sized</code>, but it needs more thought that I've given it. We're far from producing an RFC or anything like that, but have you already done some work in this area?</p>



<a name="232412669"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232412669" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232412669">(Mar 30 2021 at 11:57)</a>:</h4>
<p>My thoughts on SVE intrinsics are somewhere along the lines of: "I really hope LLVM auto-vectorization is good enough so that I don't have to deal with trying to implement this."</p>



<a name="232412896"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232412896" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232412896">(Mar 30 2021 at 12:00)</a>:</h4>
<p>SVE types lie somewhere between <code>Sized</code> types and DSTs. I think they should be mostly treated as DSTs by the type system, just with some additional capabilities such as being passed around by value. This would most likely be implemented using special compiler support rather than with a trait.</p>



<a name="232577210"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232577210" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jamie Cunliffe <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232577210">(Mar 31 2021 at 11:57)</a>:</h4>
<p>The calls to the builtins could be problematic, I remember seeing a header in LLVM that had an enum with a arm_neon_builtin name with a comment with a llvm.arm.neon.* function so my first thought was to use that to generate a bunch of links for the builtins, however, it looks like that header is built from llvm/include/llvm/IR/IntrinsicsAArch64.td (there is also an arm version of that). But I haven't actually tried any of that yet, it was the next thing I was going to investigate in a little more detail.</p>



<a name="232595298"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/232595298" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#232595298">(Mar 31 2021 at 13:56)</a>:</h4>
<p>That is incomplete, a lot of builtin lowering happens in C++ code in <code>clang/lib/CodeGen/CGBuiltin.cpp</code>.</p>



<a name="235024725"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/235024725" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#235024725">(Apr 17 2021 at 22:47)</a>:</h4>
<p><span class="user-mention silent" data-user-id="399135">Jacob Bramley</span> <a href="#narrow/stream/242906-t-compiler.2Farm/topic/stdarch-gen.20and.20neon/near/232403626">said</a>:</p>
<blockquote>
<p>We've been talking about SVE types a little, and what we might need to do to support them. My instinct is some <code>CpuSized</code> trait alongside <code>Sized</code>, but it needs more thought that I've given it. We're far from producing an RFC or anything like that, but have you already done some work in this area?</p>
</blockquote>
<p>For the <code>std::simd</code> prototype, we've had a lot of success implementing a const generic interface. By the time it becomes practical to push forward with SVE in Rust, it might be simpler to take a more direct tack and use such instead, and it would reduce the amount of (additional) compiler magic that would be required.</p>



<a name="235042191"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/235042191" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#235042191">(Apr 18 2021 at 04:22)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/242906-t-compiler.2Farm/topic/stdarch-gen.20and.20neon/near/235024725">said</a>:</p>
<blockquote>
<p>For the <code>std::simd</code> prototype, we've had a lot of success implementing a const generic interface. By the time it becomes practical to push forward with SVE in Rust, it might be simpler to take a more direct tack and use such instead, and it would reduce the amount of (additional) compiler magic that would be required.</p>
</blockquote>
<p>Hmmm, I'm unsure how this would work, since the size isn't a const.</p>



<a name="235042561"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/235042561" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#235042561">(Apr 18 2021 at 04:31)</a>:</h4>
<p>depends on what is expected~<br>
if it's the exact same binary being moved from machine to machine and running fine, that's one thing, but that might be hard to square with Rust's existing problems w/r/t ABI.<br>
if it's the same source working between machines, that's much easier.</p>



<a name="235042582"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/235042582" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#235042582">(Apr 18 2021 at 04:31)</a>:</h4>
<p>alternately, and only half a joke: higher ranked trait bounds on integers, clearly.</p>



<a name="235043207"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/235043207" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#235043207">(Apr 18 2021 at 04:45)</a>:</h4>
<p>I think it has to be the former, unfortunately. distributing $N versions of $application just to account for different SVE widths is pretty much a nightmare. also, a big part of "the point" of SVE is that the size is not known at compile time</p>



<a name="235043226"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/235043226" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#235043226">(Apr 18 2021 at 04:45)</a>:</h4>
<p>unfortunately this just... doesn't really work well with rust.</p>



<a name="236475718"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/236475718" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Bramley <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#236475718">(Apr 28 2021 at 09:23)</a>:</h4>
<p>Also note that even on the same machine, the vector length might vary from one run to the next. It's possible for the OS to artificially limit it (<a href="https://www.kernel.org/doc/Documentation/arm64/sve.txt">like this on Linux</a>). I think it's best to treat the size as constrained-unknown by default.</p>



<a name="236553774"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/242906-t-compiler/arm/topic/stdarch-gen%20and%20neon/near/236553774" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/242906-t-compiler/arm/topic/stdarch-gen.20and.20neon.html#236553774">(Apr 28 2021 at 18:14)</a>:</h4>
<p>oh _wild_</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>